TBH: I don't think we should add yet another initializer for HTTPClient.Configuration. I think we should deprecate all of them, except for init(). In init() we set all default values and then the user can change the config, since it is just a struct. We have precedent for this move in NIOSSL.

If I understand you correct, a user will then only be able to change the config by create a temporary variable, initialising it with our default config, mutating it and passing it to the HTTPClient initialiser, right? This would be a rather big change because we would need to update all our tests if we deprecate all other inits. I would rather do that in another PR if we would like to do that before merging this one.

cc @Lukasa

We could also think about adding an extension to HTTPClient.Configuration so we can change the configuration through daisy chaining like I have added in RSocket:

extension HTTPClient.Configuration {
    /// Creates a copy and updates the property described by `keyPath` with the given `newValue`
    /// - Returns: updated configuration
    public func set<Value>(_ keyPath: WritableKeyPath<Self, Value>, to newValue: Value) -> Self {
        var copy = self
        copy[keyPath: keyPath] = newValue
        return copy
    }
}

This would ease the transition because you probably end up with the same amount of lines as with an init and a user does not have to add a temporary variable.

When we are already on it, what about nested types HTTPClient.Configuration uses e.g. HTTPClient.Configuration.ConnectionPool and HTTPClient.Configuration.Timeout? They will probably suffer from the same problem, but on a much smaller scale.

I'm inclined to tackle this in a separate PR. For now we don't need to add a new init for this feature, we can just exclude it from the pre-existing inits.